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INDIVIDUAL SEAT SELECTION TICKETING 
AND RESERVATION SYSTEM 

BACKGROUND 

5 

This is a continutation-in-part of Serial No. 09/295^77, filed on April 22, 
199% entitled INDIVIDUAL SEAT SELECTION TICKETING AND 
RESERVATION SYSTEM. 

10 (1) Field of the Invention 

The invention relates to making reservations over a wide-area network. 
More specifically, the invention relates to permitting a widely distributed 
reservation system accessible over a wide-area network without dedicated 
hardware and software. 

15 (2) Background 

Various ticketing and reservation systems are disclosed in the prior art. In 
U. S. Patent 5,797,126 (1988), Helbling, et al, describes a series of individual 
kiosks in wireless communication with a central station where a visitor can locate 
events of interest, view an excerpt of scenes from that venue and purchase 

20 tickets. This requires users to physically visit a remote site to avail themselves of 
the service. Additionally, said prior art makes extensive use of what is called 
"kiosks,'* thereby requiring specialized hardware and software to render the 
services. 

U.S. Patent 4,974,252 describes a more interactive theater attendance 
25 system where patrons are permitted two way commimications between 

themselves and a broadcast center but this system requires that persons be in 
attendance at the theater and, further, some attendant be present at the remote 
broadcast center. 

Other prior art exists in the reservations arena, but typically fails to cure 
30 the shortcomings of the art set forth above. 



1 
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BRIEF SUMMARY OF THE INVENTION 

A method and system of providing distributed access to a venue 
reservation system is disclosed. A seating chart for the requested venue is served 
to an unafiliiated client node. The client tentatively selects a seat from the seating 
chart. Upon verification of the clients' payment information, the selected seat is 
designated as reserved on subsequent servings of the seating chart. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The advantages of the present invention will be more fully understood 
hereinafter as a result of a detailed description of a preferred embodiment when 
taken in conjimction with the following drawings in which: 

Figure 1 is a flow diagram of the present invention illustrating the major 
components thereof and the interactivity that takes place between the potential 
customer and the instant invention. 

Figure 2 is an illustration of the concept of the present invention utilizing 
the intemet as the Wide Area Network to which users connect to perform the 
desired function and shows an example of a remotely located user accessing the 
functionality of the instant invention for purposes of reserving seats for a dinner 
theater performance in a distant city. 

Figure 3 is a illustration of the concept of the present invention refined 
down to the functionality of reserving specific seats and blocking from duplicate 
sale those seat that are already reserved. 

Figure 4 is a sample of the screens seen by a remote user of the instant 
invention during a session wherein the user selects and orders 4 specific seats for 
a distant diimer theater show. 

Figure 5 is a complete code set for one exemplary embodiment of the 
present invention. 

Figure 6 is a flow diagram of a host server operation in response to a 
venue request in an alternative embodiment of the invention. 

Figure 7 shows a sample of seating chart in one embodiment of the 
invention. 

-2- 



wo 00/65506 



PCT/US00/106S6 



Figxire 8 is a code diagram of a code segment which implements the 
tentative reservation aspect of one embodiment of the invention. 

DETAILED DESCRIPTION 

5 

Referring to Figure 1, it will be seen that the operator of a venue 
implements the disclosed reservation system to allow remotely located users to 
reserve specific seating for specific events 1. By doing so, the operator initiates 
those certain actions necessary to displaying an internet web site to all online 

10 users 2. A prospective customer for the venues offering(s) logs onto the internet 
3 and acquires the aforesaid internet web site 4 which implements a reservation 
system for the venue. The prospective customer can be connected to the internet 
by any conventional means, yet this by no means implies that the wide-area 
network must be what is commonly referred to as the "internet." Upon contact 

15 by the prospective customer, an inquiry is directed to the appropriate database, 
which may be located concurrent with the primary server hosting the reservation 
system software program or may be located remotely, such as at the physical 
location of the venue, asking for a return of information to the prospective 
customer of all appropriate information contained therein relative to his inquiry 

20 5. The prospective customer indicates a desired seat or seats through 

conventional computer input means and directs that information back to the 
server hosting the code necessary to the implementation of the reservation 
system 6. Upon contact 7, the server again makes an appropriate database query 
and returns to the prospective customer all pertinent information relating to that 

25 selection, such as which seats are still available for the chosen performance, 

airline flight, boxing match, etc. The prospective customer is then presented with 
a representation of all then available seating for the selected venue 8. From this 
representation, the prospective customer makes a selection of a seat or seats by 
indicating such through a mouse click, keyboard entry or other means, such as 

30 but not limited to a touch screen. Selection through voice command via a speech 
interface is also within the scope and contemplation of the invention. 
Simultaneously, the server, through the coding necessary to implement the 
reservation system, creates a temporary customer identification 9 that is used to 
associate this potential customer with the customer's later selections and permit 

-3- 
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system xise by mxiltiple simultaneous users. Once the customer has made the 
seat selection, the system requests payment information from the customer 10. 
That information is processed through conventional internet or other electronic 
means, and once the information and payment are verified 11a, the customer 
5 information as supplied in 10 is made permanent, and the seat or seats selected 
are removed from inventory and blocked from duplicate sale, both graphically 
when presented to the next prospective customer and in the database where 
information for accounting and administrative purposes is retained. If the 
customer's payment ir\formation cannot be verified lib, then the customer is 

10 given an opportunity to correct the information or start over with a new 

transaction. Upon verification of the customer's payment information, the 
customer receives a confirmation of the transaction 13 contaiiung all appropriate 
reference information for the customer's records. 

Referring to Figure 2, it will be seen that, for example, a user in Houston 

15 13 is planning to vacation in New York and wishes to see a play at a dinner 

theater there that utilizes the system for ticketing and reservations 15. The user, 
in Houston, or in any other location worldwide, connects to the internet in the 
conventional way and retrieves the appropriate web site through a graphical 
browser from a host server located in, say, Anaheim, California 14. Notably, the 

20 client node is unafilliated with the host server, i.e., need not have dedicated 
hardware or software to access the system. Rather, the system may be made 
accessible through any conventional web browser. The host server serves a 
seating chart for the diimer theater to the user such that the user is able to see the 
exact seating arrangement of the remote dinner theater and select the exact seat 

25 or seats desired for the performance of choice. Such additional information as is 
appropriate can be provided to the remote user to assist in making an informed 
decision as to which seat or seats are desired. By way of example, the host server 
may serve a view as seen from a particular seat tentatively selected. For 
example, in one embodiment, the tentative selection may be through clicking on 

30 the seat or merely detection of the cursor over the seat without a click. While in 
this example, the "venue" is a dinner theater, venue as used herein is not so 
limited and is deemed to include any forum for which seating space is sought, 
including without limitation, airplane or other trarisportation, stadiums, theaters, 
and the like. 

-4- 
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Referring to Figure 3, it will be seen that in view (a) of the user selected 
venue all seats at table Pll 17 and at table S14 18 have been previously taken and 
are so indicated by the graphical representation of an "X" over those seats. The 
potential customer wants to seat a party of four at table SI 16 and so indicates by 
5 clicking the mouse on those four seats or by so indicating through alternative 
standard computer input means. Once his payment method is verified, the 
selected seats are removed from inventory and so indicated on the graphical 
representation by placing an "X" over those seats 19 while retaining the "X" over 
those seats previously sold at table Pll 20 and table S14 21. The next prospective 

10 customer is advised that these seats are no longer available for this performance 
by the new graphical representation that is the subsequent customer's first 
viewing screen upon entry into the system. In the event that two prospective 
customers wish to reserve the exact same seat or seats, that prospective customer 
who first receives validation of the payment method is given those seats, while 

15 the other prospective customer is notified that the seats desired have already 
been sold and offers a chance to select other seating. 

Figure 4 shows the screens presented to a user when accessing the system 
and progressing through the process of selecting a specific seat or seats, and 
reserving and paying for them. Figure 4(a) is where the first screen presented 

20 shows links to available performances for that selected venue 22. Figure 4(b) is 
the second screen 23 and shows a view of the seating available for that venue 
with seats that have already been taken crossed off with an "X" 24. The 
hypothetical user wants to have a party of four sit at table Sll 25 and selects the 
four seats aroimd that table by clicking on them with the mouse. As the mouse 

25 moves the cursor over individual seats, the seat number appears in the window 
at the bottom of the user's screen 26 and when the user dicks on a seat, it is 
added to a nmning tally of the seats the user has already taken 27. Only seats 
having not previously been taken show up in the window 26 when the cursor 
passes over them. After completing the selections, the user clicks on the "Reserve 

30 Seats" button and Figure 4(c) shows the next screen which requests payment 
information 28. The user enters the required information and again clicks the 
"Reserve Seats" button 29. Figure 4(d) is the next screen and it tells the user that 
the payment method has been accepted (or rejected) and relates information 
about the transaction 30 such as a transaction code and a receipt nim\ber that can 
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be used as a ticket or as a voucher with which to redeem a ticket or tickets at the 
venue box office upon arrival for the performance. Finally, Figure 4(d) shows the 
opening screen the next visitor to the system is presented with, which is the same 
set of screens except that the seats reserved by the hypothetical user 31 are 
marked off as already taken. 

Figure 5 is a code diagram of one embodiment of the invention. The 
ticketing and reservation system of the present invention, in one particular 
embodiment thereof, includes a computer program operating on a server for a 
wide area network (WAN), generally described by the flow chart of Figure 1 and 
the accompanying code example which implements one embodiment of the 
instant invention. First, when a user accesses the system means is provided to 
initialize the process and return to the user a menu from which he selects his 
venue of interest. This can be a selectable menu arranged by artist or date or 
time or specific theater or football team or baseball team or name or activity or 
any combination thereof such that the user is given sufficient information from 
which to make a decision. An example would be someone looking for the next 
event at a given theater at a time that starts at 7:00pm. One of many possible 
series of computer instructions to perform this function is: 

< -.Send database query to retrieve all venues that are currently 
available in the system - > 

< - Server receives and processes query - > 

< - Query is looped until all available performances and venues are 
retrieved. - > 

< - Markup Language engine converts result to display compatible 
format for output to client computer - > 

< - Begin normal markup language here - > 

< - Begin reservation process selecting the event date/ time next to 
the desired venue -> 

Then, upon user submittal, the server initializes the process of returning to 
the user all available seats: 

< -.Send database query to retrieve all seats that are currently 
available in the system for this event - > 

< - Server receives and processes query - > 

< - Query is looped imtil all available seats are retrieved, - > 
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< - markup language engine converts result to markup language 
format for output to client computer - > 

< - Begin normal markup language here - > 

< - Continue reservation process by selecting the desire seat or seats 
-> 

Then, upon xiser submittal, a new customer record is created in the Wide 
Area Network server and the system is notified which database to connect to to 
fulfill the users request(s): 

< - Send database command to insert new record in customer 
database and obtain record id - > 

< - Send database command to insert new record in reservation 
"order" database and obtain record id - > 

< - Send database command to insert new record for each selected 
seat in the reservation "detail" database - > 

< - Begin normal markup language here - > 

< - Continue reservation process by requesting client payment 
information - > 

Then, upon user submittal the information is passed for verification: 

< - Submit client information for verification - > 

< - if verification is successful, send database command to update 
customer record in customer database with information previously 
collected - > 

< - if verification is successful, send database command to update 
reservation record in reservation "order" database with verification 
information - > 

< - if verification is successful, send database command to remove 
selected seats from seat inventory database and marked as no 
longer available for future selection - > 

< - Markup language engine converts result to markup language 
format for output to client computer - > 

< - Begin normal markup language here - > 

< - If verification is successful, confirmation is generated via 
Markup language engine to markup language format for output to 
client computer - > 
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wo 00/65506 



PCT/USOO/10686 



< - if verification is unsuccessful, a failure notice is generated via 
Markup language engine to markup language format for output to 
client computer - > 

< - if verification is unsuccessful, client is presented with option to 
provide his payment information again or abandon his reservation 
- > 

While this is one preferred form of the code there are memy other code sequences 
that will perform the same function that will be immediately obvious to one 
skilled in the art. 

Figure 6 is a flow diagram of a host server operation in response to a 
venue request in an alternative embodiment of the invention. A host server 
receives a venue request at functional block 600. Then, at functional block 602, 
the host server serves a seating chart for that venue to the requesting client node. 
In one embodiment, the seating chart is served as a HTML page with active links 
for the seats which are currently available. In another embodiment, the seating 
chart may be served as a Java applet. At functional block 604, the host server 
receives a tentative seat selection from the client node. Then at decision block 
606, a determination is made on the host server whether the tentative seat 
selection selected at functional block 604 would orphan one or more seats. An 
orphan seat is deemed to be any single seat that has no available a? seat within 
the row. 

Some venues may wish to force alternative seat selections if the tentative 
seat selections would orphan seats. Following alternative seat selection and the 
criterion for doing so may differ from venue to venue, as well as depending on 
the existing availablity of comparable seating that would not orphan seats. A 
determination is made by the host server seat at decision block 608 whether the 
selected venue wishes to force alternative seat selection. If the venue does not 
wish to force alternative seat selection, the host server may optionally 
nevertheless send a request that alternative seats be selected at ftmctional block 
610. A determination is made at decision block 612 after the request that 
alternative seats be selected is sent at functional block 610 whether the client 
node has accepted the request. Alternatively, if the venue wishes to force 
alternative seat selection at functional block 608, a message indicating that the 
selected seats are imavailable and possibly explaining that the venue does not 
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permit seat selection that would orphan seats sent to the client node at functional 
block 614. 

If at decision block 612, the request has been accepted, suggested 
alternative seat selections may be sent at functional block 616. The alternative 
5 suggested seat selections may also be sent subsequent to the notice that selected 
seats are unavailable at functional block 614. After the suggested alternative seat 
selection is sent at functional block 616, the determination is made whether the 
suggestion has been accepted by the client at decision block 618. If the suggested 
alternative seat selection is not accepted, a determination is made at decision 

10 block 620 whether cin alternative seat selection has been received, e.g., different 
than the original tentative seat selection and different from the suggested 
alternative seat selection. If not, the interaction with the client ends. If it has, the 
server makes an orphan determination as to the new alternative seats. After the 
request is not accepted at decision block 614, or no seats would be orphaned at 

15 decision block 606, the server places a tentative reservation on the seats at 

functional block 622. Alternatively, the tentative reservation may be made prior 
to the orphan determination and cancelled if alternative seats are forced or 
selected. Once the tentative reservation is placed on the seats, all subsequent 
users accessing the server will be served the seating chart with the tentative seats 

20 shown in a representation that is different from both the representation of sold 
seats and the representation of unsold seats. This is termed the tentative reserve 
representation. In one embodiment, this takes the form of a question mark 
appearing over the seats, as displayed on the seating chart. 

At functional block 624, a request for payment information is issued by the 

25 host server. A determination is made at decision block 626 if the payment 

information received is valid. If the payment information is not valid, a request 
is made by the server at functional block 628 for alternative payment information 
coupled with an indication that the prior payment information was unacceptable. 
If the alternative payment information is received at decision block 630, that 

30 payment irif ormation is then verified at functional block 626. If not, the tentative 
reservation is removed at functional block 632. This returns the representation of 
the seat on subsequently served seating charts to the imsold representation. If 
the payment information is valid at decision block 626, the reservation is made 
permanent, and the representation of the seat on the seating chart is changed to 
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the permanently reserved reservation representation. A printable receipt, ticket, 
or voucher sufficient to permit access to the event is then served to the client 
node. 

Figure 7 shows a sample of seating chart in one embodiment of the 
invention. As shown in the figure, seats C and D in row 10 are shown in a 
tentatively reserved representation. The "Xs" mark seats which are permanently 
reserved, and the circles with no indication represent seats in the unsold state. 
Seat 10(i) would be considered an orphan seat. 

Figure 8 is a code diagram of a code segment which implements the 
tentative reservation aspect of one embodiment of the invention. Ntmierous 
other codings are, of course, possible. 

Those having skill in the art to which the present invention pertains will 
now imderstand that there are virtually unlimited uses for the present invention. 
By way of example, the present invention may be readily used to reserve specific 
seats on commercial airliners or reserve specific staterooms on a cruise ship, as 
well as for reserving seats for any venue from commimity theater or little league 
basebaU to major league sporting events. 

In the foregoing specification, the invention has been described with 
reference to specific embodiments thereof. It will, however, be evident that 
various modifications and changes can be made thereto without departing from 
the broader spirit and scope of the invention as set forth in the appended claims. 
The specification and drawings are, accordingly, to be regarded in an illustrative 
rather than a restrictive sense. Therefore, the scope of the invention should be 
limited only by the appended claims. 
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CLAIMS 



What is claimed is: 

1 1. A method comprising: 

2 transmitting specific seat availability information to a user across a 

3 wide area network to an unaffiliated client node; 

4 receiving an indication of tentative seat selection from the user 

5 across the wide area network; cmd 

6 accepting payment from the user; and 

7 denoting the seat as tmavailable to future users. 

1 2. The method of claim 1 further comprising: 

2 indicating to any subsequently requesting client node that the 

3 tentative seat selections are tentatively unavailable xmtil a transaction is 

4 completed or voided. 

1 3. The method of claim 1 further comprising: 

2 identifying if the tentative seat selection would orphan at least one 

3 imselected seat. 

1 4. The method of claim 3 further comprising: 

2 denying a reservation of the tentative seat selection if the tentative 

3 seat selection would orphan at least one imselected seat. 

1 5. The method of claim 3 further comprising: 

2 requesting that the user make a different selection if the tentative 

3 selection would orphan at least one seat; and 

4 suggesting a different selection that would not orphan at least one 

5 seat. 

1 6. The claim of 5 further comprising: 

2 denying a reservation of the tentative seat selection if the tentative 

3 seat selection would orphan at least one selected seat if alternative seats of a 

4 same class are available that would not orphan a seat. 
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1 7. The method of claim 2 wherein indicating comprises: 

2 changing a representation of a seat from a first representation to a 

3 second representation; and 

4 transmitting the second representation to a client node. 

1 8. The method of claim 7 further comprising: 

2 changing the representation of the seat from the second 

3 representation to a third representation if the transaction is completed; and 

4 changing the representation of the seat from the second 

5 representation to the first representation of the transaction is voided. 

1 9. The method of claim 1 further comprising: 

2 providing additional information about the tentative seat selection 

3 to the user across the wide area network. 

1 10. A system comprising: 

2 a host server coupled to a wide area network (WAN); and 

3 a database coupled to the server, the database, the database poptilated 

4 with entries reflecting seating availability for at least one venue; 

5 wherein the host server serves seating information on demand responsive 

6 to a request of an imaffiliated node. 

1 11. The system of claim 10 wherein seating information comprises: 

2 a seating chart for the venue showing available seats in a first 

3 representation, tentatively unavailable seats in a second representation, and 

4 unavailable seats in a third representation; 

1 12. The system of Claim 10 wherein the server serves pages providing 

2 a graphical user interface from which a user may select specifically desired seats 

3 from the venue. 

1 13. A method comprising: 

2 requesting a venue at an unafilliated client node from a host server; 

3 receiving a seating chart for the venue; 

4 tentatively selecting seats shown in a first representation from the seating 

5 chart; and providing payment information. 
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14. The method of claim 13 further comprising; 

receiving the seating chart showing the tentatively selected seats in a 
second representation while a transaction is pending. 

15. The method of claim 14 further comprising; 

receiving the seating chart showing the tentatively selected seats in a third 
representation once the transaction is complete; and 

receiving a printable electronic receipt sufficient to permit access to the venue. 

16. A method comprising: 

(a) communicating on demand, from an information server through a 
wide area network to a device connected to the wide area network information 
from a database populated by a multiplicity of entries denoting availabihtyfor a 
venue; 

(b) displaying the information such that an end-user connected to the 
wide area network can view the information on a client node xmaffiliated with 
the server as an aid in determining a best then available space conforming to a 
need of the end-user; 

(c) providing over the wide area network to the end user the capability 
of interactively selecting a time, a space, and a seat of choice; 

(d) accepting over the wide area network from the end user a payment 
for one of the time, the space, and the seat selection of choice; 

(e) returning over the wide area network to the end user verification of 
the successful completion of the payment. 

17. The method described in claim 16 wherein the space, the time, and 
seat sought is for a theater or theater type setting. 
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2 18. The method described in claim 16 wherein the space, the time, and 

3 the seat sought is for a stadium type setting. 

1 19. The method described in daim 16 wherein the space or time or seat 

2 or seating sought is for an airplane or airliner. 

1 20. The method described in claim 16 wherein the space or time or 

2 reservation sought is accommodations on a cruise ship. 

1 21. The method described in claim 16 wherein a communication 

2 connection between the ii\formation server and the end user includes one of a 

3 wire, a cable, and a telephone line connection. 

1 22. The method described in claim 16 wherein a communication 

2 coimection between the information server and the end user includes a satellite 

3 link, 

1 23. The method described in claim 16 wherein a communication 

2 connection between the information server and the end user includes a wireless 

3 link. 

1 24. The method described in claim 17 wherein the communication 

2 connection between the information server and the end user is wireless. 

1 25. A method comprising: 

2 receiving at a server a request for a venue from at least one client node 

3 remote from and unaffiliated with the server; 

4 transmitting from the server an indication of specific availability 

5 responsive to the request, the indication of specific availability directed to the 

6 client node; 

-14- 
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receiving a specific indication of a client preference at the server; 
removing the client preference from any future indication of specific 
availability. 

26. The method of claim 25, wherein the specific availability includes 
seating, further comprising: 

retrieving from a database an image showing a view from a seat indicated 
by the client preferences- 
transmitting the image to the client. 

27. The method of claim 25, wherein the indication of specific 
availability includes a graphical representation of at least a portion of a seating 
chart for the venue, and wherein the graphical representation shows availability 
seats in a first representation and previously sold seats in a second 
representation. 

28. The method of claim 25, wherein the indication of the specific 
availability is transmitted as one of a hypertext markup language page and a java 
applet, 

29. The method of claim 27 further comprising: 

linking the representation of a seat to an image of a view from that seat. 

30. The method of claim 25 further comprising: 

accepting payment information at the server sufficient to permit access to 
the specific client preference; 

conducting an electronic payment transaction; and 
providing an electronic receipt. 

-15- 
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31 . A method comprising: 

requesting information about a venue across a wide area network (WAN) 
from a client node to be supplied by an unaffiliated server node; 

receiving an indication of specific availability at the client node; 

selecting from a plurality of specific availability options a specific client 
preference; and 

receiving an indication that the specific client preference has been 
reserved through the server node. 

32. The method of claim 31 wherein the indication of specific 
availability includes a graphical representation of at least a portion of a seating 
chart for the venue, and wherein the graphical representation shows available 
seats in a first representation and previously sold seats in a second 
representation. 

33. The method of claim 32 wherein selecting comprises: 
clicking on a desired seat. 

34. The method of claim 33 further comprising: 

receiving an image of a view from the desired seat responsive to the 
clicking. 

35. The method of claim 31 further comprising: 

supplying payment information for the specific client preference; and 

receiving an electronic receipt sufficient to permit access to the specific 
client preference. 

-16- 
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1. A venue operator implements the instant 
invention for his use as his own ticketing and 
reservation system. 




2. That specific venue is recorded, coded and placed 
on a server connected conventionally to the internet 
or any such wide area netwoifc 








3. A prospective customer for tickets to any 
some event logs onto the internet, or other 
such wide area network, in his conventional 
manner, whether from home or o£Ece or any 
remote location. 


> 


4. Said prospective customer attaches to the server 
through any conventional gr^hical browsing means 
and views the available venues, performances, dates, 
and/or other such offerings. 






I 






6. Said prospective customer selects a specific 
area ofinterest from the available venues. Such 
may be theater tickets for a particular show date, 
airline seats for a given flight, etc., and indicates 
his selection through a conventional hyperlink 
or other compatible means. 




5. Upon first access an inquiry is made to the 
appropriate database asking for a return to the 
prospective customer of all generalized information 
available from which he will make a selection of the 
type of venue he is seeking. 







1. Upon contact the server makes another 
appropriate database query asking for a return to 
the prospective customer of all specific 
information relating to his selection, Le., 
available seats for Ae chosen airline flight, fix>m 
which he will make his selection or selections. 



8. Upon return the prospective customer is 
presented with a representation of all available 
seating for his selected venue. From this 
representation, which may be graphical or displayed 
in any other appropriate way, he makes a selection 
of the specific seat or seats he wishes to reserve and 
submits such to the server. 



1 0. The server requests payment information 
from the now customer through a form input 
mechanism. Once completed and submitted 
customers payment information is verified 
through conventional means with any of the 
existing processing means. 



9. The server creates a temporary customer 
identification and associates the prospective 
customers selections with that specific identification 
so as to preclude confusion and allow multiple 
simultaneous users. 




] 1(A). If customer's payment information 
verification is successfiil then: 

(a) the customers information, as supplied in 
Step 10, is made permanent and; 

(b) those specific seats as selected by die 
customer are removed from available 
inventory and; 

(c) marked as unavailable on the graphical 
representation of die venue seating as 
presented to the next prospective customer; 

(d) entered into the accounting and 
administration information database for later 
retrieval by the venue operator.. 



1 1(B). If customers paymenfrnformation verification is 
not successful tiien: 

(a) customer is given the opportunity to correct his 
submittal and try again; 

(b) customer can return to the beginning and repeat the 
entire process. 



12. A confirmation of the transaction, containing the 
transaction identification and other pertinent 
information is returned to the customer 



Figure 1 
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Figure 2 
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Figure 3a 




Figure 3b 
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Start Figure 4 



Figure 
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Figure 4(b) 
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Figure 4(d) 



wo 00/65506 



8 / 41 



PCTAJSOO/10686 




wo 00/65506 



9 / 41 



PCT/USOO/10686 



Start Figure 5 

Begin Program 
<Markup language> 

<REM — Imports the file "datasource.inc" which creates variable "datasovirce" 
which is used to tell markup language datasomce to connect to. 

- > 

<INCLUDE NAME="database\datasource.inc"> 

<REM — In case a database or other type of error occurs, this display the error 

message. —. > 

<ERROR> 

<FONT FACE="Verdana, Arial" SIZE="+l"><B>An Error Has 
Occurred</B></FONT><P> 

<FONT FACE="Verdana, Arial" SIZE="-l"><B>Error Message = :i_errortext 
</B></FONT><P> 

<FONT FACE="Verdana, Arial" SIZE="-l"><B>database Error = 
:i_databaseerrortext</B></FONT><P> 

<FONT FACE="Verdana, Arial" SIZE="-l"><B>database Error = 

:i_databaseerrorstmt 

</B></FONT><P> 

</ERRGR> 

<REM — Begin normal markup language here — > 

<markup language> 

<HEAD> 
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<T[TLE>Ticketing &:amp; Reservation System</TITLE> 
</HEAD> 

<BODY BACKGROUND=t"images/background.jpg" TEXT="#000000" 

LINK="#006666" VLINK="#006666"> 

<CENTER> 

<IMG SRC="iinages/masthead_concerts.gif' HEIGHT=60 WIDTH=280><P> 
<FONT FACE='Verdana,Ariar SIZE=-l><B>To begin reserving your seat(s), 
please select the concert date/time you wish to attend next to the performer you 
want to see:</B></FONT> 

<TABLE BORDER=0 CELLSPACING=5 CELLPADDING=5> 
<REM — Begin database query to retrieve all performances that is — > 
<REM — currently available. Will loop until all available — > 
<REM ~ performing artists and their performances are listed. — > 
<REM — Part of the return from the query are the links that will — > 
<REM ~ take you to the next step of the reservation. — > 

<database DBNAME=":datasource" 

database="SELECT id, name, picture, sequence 

FROM category 

WHERE active=l AND parent=-l 
ORDER BY sequence" 
ALIAS="concert"> 
<databaseFETCH ALIAS="concert"> 
<WHILE NOTALIAS=i_databaseempty> 
<TR> 
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<TD COLSPAN=2> 
<FONT FACE="Verdana,Arial" 
SIZE=+l><B>:concert_name</B></FONT> 

</TD></TR><TR><TD VALIGN="top"> 

<img src=iinages/;concert_picture align=top border="l"> 

</TD><TD> 

<Markup language DBNAME=":datasource" 
database="SELECT id, name, date, time 
FROM category 

WHERE active=l AND parent=:concert_id 
ORDER BY date, time" 

OUTPUT="<FONT FACE='Verdana,Arial' SIZE=-1><B> 
<A HREF=*reservel.ihtml?&id=:l'>:2</A> 
</B></FONT><p>"> 

</TD></TR><TR><TD COLSPAN=2><HR></TD></TR> 

<databaseFETCH ALIAS="concert"> 

</WHILE ALIAS=i_databaseempty> 
</database ALIAS="concert"> 
</TABLE> 
</BODY> 

</markup language> 
processing then passes to: 
<Markup language> 

<REM — Imports the file "datasource.inc" which creates the — > 
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<REM — variable "datasource" which is used to tell Markup language which 
- > 

<REM — database datasource to coimect to. ~ > 

<INCLUDE NAME="database\datasource.inc"> 

<REM In case a database or other type of error occurs, this will display the error 

message. > 

<ERROR> 

<FONT FACE="Verdana^rial" SI2E="+l"><B>An Error Has 
Occurred</B></FONT><P> 

<FONT FACE="Verdai\a,Arial" SIZE="-l"><B>Error Message = 
:i_erTortext</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 
:i_databaseerrortext</B></FONT><F> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 

:i_databaseerrorstmt</B></FONT><P> 

</ERROR> 

<REM — Begin normal markup language here — > 

<markup languago 

<HEAD> 

<'nTLE>Ticketing & Reservation System - Select Seat(s)</'nTLE> 
</HEAD> 

<REM ™ All seats clicked will pass its information to a input box, "newseats". 
When done, the information will be passed to "process.ihtml" and be processed 
by "reserve2.ihtml". ~ > 
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<REM ™ This code allows the ability to select multiple seats before proceeding to 
the next step of reservation process. Other features include listing the selected 
seats in the "number" text box to show the seats that has been clicked. This script 
also alters the button text to be grammatically correct. ™ > 
<SCRIPT LANGUAGE="JavaScript"> 

<!" 

function selectseat(idnum, seatnum) 
I 

reserved = document.seats.number. value; 

if (reserved == "") 

{ 

document.seats.newseats.value = "<Markup language DBNAME=:"+"datasource 
database=*INSERT INTO basket (custid, pid, qty) VALUES (:"+"custid, 
"+idnum+", l)'><database DBNAME=:"+"datasource database='SELECT cost 
FROM products WHERE id="+idnum+"'><databaseFETCH><iEQ 
NAME='ticketprice' VALUE=:"+"l></database><iEQ NAME^'total' 
VALUE=<iEVAL EXPR=':"+"ticketprice + :"+"total' PREC='2*»<Markup 
language DBNAME=:"+"datasource database='INSERT INTO orderdetail (pid, 
oid, qty, seU) VALUES ("+idnum+", :"+"oid, 1, :"+"ticketprice)'>"; 
document.seats.number.value - seatnum; 
document.seats.buttonl. value = "Reserve Seat"; 
document.seats.button2.value = "Clear Oioice"; 

) 

else 
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{ 

doctiinent.seats.newseats.value += "<Markup language 
DBNAME=:"+"datasource database='INSERT INTO basket (custid, pid, qty) 
VALUES (:"+"custid, "+idnum+", l)'><database DBNAME=:"+"datasotirce 
database='SELECT cost FROM products WHERE 
id="+idnum+"'><databaseFETCH><iEQ NAME='ticketprice' 
VALUE=:"+"l></database><iEQ NAME='total' VALUE=<iEVAL 
EXPR=':"+"ticketprice + :"+"total' PREC='2'»<Markup language 
DBNAME=:"+"datasource database='INSERT INTO orderdetail (pid, oid, qty, 
sell) VALUES ("+idnum+", :"+"oid, 1, :"+"ticketprice)'>"; 
document.seats.number.value = reserved+", "+seatnum; 
document.seats.buttonl .value = "Reserve Seats"; 
document.seats.button2,value = "Clear Qioices"; 

) 
) 

function clear() 
{ 

document,seats.newseats-value = 

) 

//-> 

</SCRIPT> 

<BODY BACKGROUND="images/background.jpg" TEXT="#000000" 
LINK="#006666" VLINK="#006666"> 



wo 00/65506 PCTAJSOO/10686 

15 / 41 

vn 

<REM — Begin database query to retrieve the last id number from table 
"orderdetail" for the purpose of creating a new instance of the stage image 
whenever a new order has occurred. This will prevent tiie browser from 
displaying an old floor image from its cache as a different image name is called 
every time the file is run. — > 
<database DBNAME=":datasource" 

database="SELECT max(id) 

FROM orderdetaU"> 

<databaseFETCH> 

<iEQ NAME="imagenum" VALUE=:1> 
<databaseFETCH> 
</database> 

<iEQ NAME="imagetype" VALUE=".jpg"> 
<CENTER> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=5 CELLSPACING=0 

WIDTH=500> 

<TR><TD><CENTER> 

<FONT FACE='Verdana,Arial' SIZE=+1 COLOR='#FFFFFF'><B> 

Concert Reservation System 

</B></FONT> 

</CENTER> 

</TD></TR></TABLE></CENTER><p> 

<REM - Loads the core image that will be dynamically altered for use as the 
image map. - > 
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<iIMAGEFROMFILE NAME="stage" FILENAME="images/stage.jpg" 
TYPE="jpeg"> 

<MAP NAME="stage" BORDER=0> 

<REj^ — Begin database query to retrieve all seat information for the image map 
"stage". Will loop until all available seat information for this particular 
performance is listed. — > 

<REM — The return query will be used only if the "active" attribute of that 
particular seat is marked "true" or "1". — > 

<REM — If active, the seat's information, including image map coordinates will 
be displayed. Otherwise, the seat on the image map will be x'd out according to 
the X and y coordinates associated with it. ~ > 

<database DBNAME=":datasource" 

database="SELECr id, active, x, y, shape, corrds, name, mouseout, mouseoverl, 
mouseover2, mouseoverS 

FROM products 

WHERE catid=:id"> 

<databaseFETCH> 

<iWHILE NOTALIAS=i_databaseempty> 

<iEQ NAME="active" VALUE=:2> 

<iCASE ALIAS="active" VALUE=1> 
<AREA SHAPE= "iS" COORDS=":6" HREF="javascript:selectseat(:l,':r)" 
ALT="Seat # T OnMouseOut=:8 OnMouseOver=:9 :7 :10 :7 :11 > 

</iCASE ALIAS="active"> - 

<iCASE ALIAS="active" VALUE=0> 
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<iIMAGETEXT NAME="stage" TEXT="X" X=:3 Y=:4 COLOR="red"> 

</iCASE ALIAS="active"> 

<databaseFETCH> 

</iWHILE ALIAS=i_databaseempty> 
</databas€> 
</MAP> 
<CENTER> 

<FONT FACE="Verdana^rial" SIZE="-1"><B> 
Click on the seat you wish to reserve. 
</B></FONT> 

<TABLE BORDER=l CELLPADDING=0 CELLSPACING=0> 
<TR><TD> 

<REM — Converts the dynamically generated image, "stage", into a web friendly 
image type - "jpeg". — > 

<nMAGEVyRITE NAME="stage" FILENAME="images/ch_stage-:id- 
:imagenum:imagetype" TYPE="jpeg" QUALrrY="30"> 
<REM — Deletes the temporary image "stage" as it is no longer needed. — > 
<iIMAGEDESTROY NAME="stage"> 

<IMG SRC="images/legend.jpg" BORDER=0 HEIGHT=20 WIDTH=584><BR> 

<IMG SRC="images/ch_stage-:id-:imagenum:imagetype" BORDER=0 

USEMAP="#stage" HEIGHT=315 WIDTH=584> 

</CENTER> 

</TD></TR></TABLE> 

<FONT FACE='Verdana,Ariar SIZE=-1><B> 
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An "X" denotes a seat that has already been taken. 
</B></FONT> 

<FORM NAME="seats" ACTION="process.ihtmr METHOD="post"> 
<CENTER> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=0 CELLSPACING=0> 
<TR><TD> 

<TABLE BGCOLOR=*#FFFFFF' BORDER=0 CELLPADDING=5 

CELLSPACING=1> 

<TR><TD><CENTER> 

<FONT FACE='Verdana,Arial' SIZE=-1><B> 

Your mouse is over seat#: <INPUT TYPE="text" NAME="seatnum" SIZE=5> 
</B></FONT></CENTER> 
</TD>< /TR><TR><TD><CENTER> 
<FONT FACE='Verdana,Ariar SIZE=-1><B> 

Selected Seats:<BR><INPUT TYPE="text" NAME="number" SIZE=40> 
<BR> 

<INPUT TYPE="hidden" NAME="newseats" SIZE=50> 

<INPUT TYPE="submit" NAME="buttonl" VALUE="Reserve 

Seat"> <INPUT TYFE="reset" NAME="button2" VALUE="Clear Choice" 

onClick="clear()''> 

</B></FONT> 

</CENTER> 

</TD></TR></TABLE></TD></TR></TABLE></CENTER> 
</FORM></CENTER></BODY> ^ 
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</markup languago 

which then passes to a template: 

<Markup language> 

<REM — Imports the file "datasource.inc" which creates the variable 
"datasource" which is used to tell Markup language which ODBC datasource to 
coimect to. 

<iINCLUDE NAME="database\datasource.inc"> 

<REM — In case a database or other type of error occurs, this will display the 

error message. - > 

<ERROR> 

<FONT FACE="Verdana,Arial" SIZE="+l"><B>An Error Has 
Occurred</B></FONT><P> 

<FONT FACE="Verdana,Ariar' SIZE="-l"><B>Error Message = 
:i_errortext</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 
:i_databaseerrortext</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 

:i_databaseerrorstmt</B></FONT><P> 

</ERROR> 

<REM Copy a preformatted file, "empty .ihtml" into a new file, — > 
<REM ™ "reserve2.ihtml", — > 

<iCOPYFILE SRC="empty .ihtml" DST="reserve2.ihtmr'> 



wo 00/65506 PCTAJSOO/10686 

20/41 

xn 

<REM — Appends the information passed from "resevel.ihtml" to 
"reserve2.ihtml" for process. Other html information is also passed, 
.«> 

<iFILE NAME="reserve2.ihtml" DATA=":newseats" OP="append"> 

<inLE NAME="reserve2,ihtml" DATA="<INPUT TYPE=*hidden* 

NAME='totar VALUE=:total>" OP="append"> 

<iFILE NAME="reserve2.ihtml" DATA="</FORM>" OP="append"> 

<iFILE NAME="reserve2.ihtml" DATA="</CENTER>" OP="append"> 

<iFILE NAME="reserve2.ihtml" DATA="<P>" OP="append"> 

<iFtLE NAME="reserve2.ihtmI" DATA="</BODY>" OP="append"> 

<iFILE NAME="reserve2.ihtnU" DATA="</markup languago" OP="append"> 

<REM — Once the information is appended into "reserve2.ihtmr', it will be 

automatically push the page "reserve2.ihtmr* to the browser. 

-.-> 

<iREDIR URL="reserve2.ihtml"> 

which then combines information and passes to: 

<Markup language> 

<REM ™ Imports the file "datasource.inc" which creates the variable 
"datasource" which is used to tell Markup language which ODBC datasource to 
connect to. — > 

<iINCLlJDE NAME="database\datasource,inc"> 

<REM In case a database or other type of error occurs, this will display the 

error message. - > 

<ERROR> 
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<FONT FACE="Verdana,Arial" SIZE="+l"><B>An Error Has 
Occurred</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>Error Message = 
:i_errortext</B></FONT><P> 

<FONT FACE="Verdana^rial" SIZE="-l"><B>database Error = 
:i_databaseerrortext</B></FONT><P> 

<FONT FACE='Verdana,Ariar SIZE="-l"><B>database Error = 

:i_databaseerrorstmt</B></FONT><P> 

</ERROR> 

<REM — Copy a preformatted file, "empty .ihtml" into a new file, 
"reserve2.ihtmr. — > 

<iCOPYFILE SRC="empty.ihtml" DST="reserve2.ihtml"> 

<REM — Appends the information passed fi"om "resevel.ihtml" to 

"reserve2.ihtml" for process. Other html information is also passed. — > 

<iFILE NAME="reserve2.ihtmr DATA=":newseats" OF="append"> 

<iFILE NAME="reserve2.ihtml" DATA="<INPUT TYPE='hidden' 

NAME='total* VALUE=:total>" OP="append"> 

<iFILE NAME="reserve2.ihtml" DATA="</FORM>" OP="append"> 

<iFILE NAME="reserve2.ihtmr DATA="</CENTER>" OP="append"> 

<inLE NAME="reserve2.ihtml" DATA="<P>" OP="append"> 

<iFILE NAME="reserve2.ihtml" DATA="</BODY>" OP="append"> 

<iFILE NAME="reserve2.ihtml" DATA="</markup languago" OP="append"> 

<REM — Once the information is appended into "reserve2.ihtml", it will be 

automatically push the page "reserve2.ihtml" to the browser. 
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<iREDIR URL="reserve2.ihtinl"> 

then (takes all information from index & reserve one and conbines it to with the 
information in empty) then passes to: 
<!Markup language> 

<REM — Imports the file "datasource.inc" which creates the variable 
"datasource" which is used to tell Markup language which ODBC datasource to 
connect to. — > 

<iINCLUDE NAME="database\datasource.inc"> 

<R£M " In case a database or other type of error occurs, this will display the error 

message. — > 

<ERROR> 

<FONT FACE="Verdana,Arial" SIZE="+l"><B>An Error Has 
OccurTed</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>Error Message = 
:i_errortext</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 
:i_databaseerrortext</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 

:i_databaseerrorstmt</B></FONT><P> 

</ERROR> 

<REM — Begin normal markup language here — > 

<markup languago 

<HEAD> 

<'nTLE>Ticketing & Reservation System - Customer Information</'nTLE> 
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</HEAD> 

<BODY BACKGROUND="images/background.jpg" TEXT="#00OO00" 
LINK="#006666" VLINK="#006666"> 

<REM Get Customer Info — > 

<CENTER> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=5 CELLSPACING=0 

WIDTH=500> 

<TR> <TD><CENTER> 

<FONT FACE='VerdanaArial' SIZE=+1 COLOR='#FFFFFF'><B> 

Ticketing & Reservation System 

</B></FONT> 

</CENTER> 

</TD></TR> 

</TABLE><p> 

<FORM ACTION=reserve3.ihtml METHOD=POST> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=0 CELLSPACING=0> 
<TR><TD> 

<TABLE BGCOLOR='#FFFFFF' BORDER=0 CELLPADDING=5 
CELLSPAC3NG=1> 
<TR> 

<TD COLSPAN=2><CENTER><FONT FACE='Verdana,Ariar SIZE=- 
1><B>CUST0MER INFORMATION</CENTER></TD> 
</TR><TR> 
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<TD><FONT FACE='Verdana,Arial' SIZE=-l><B>Name as appear on 
CC</B></FONl></TD> 

<TD><FONT FACE='Verdana,Arial' SIZE=.1><B><INPUT TYPE="text" 
NAME="name" MAXLENGTH=50 SIZE=40></B></FONT></TD> 
</TR><TR> 

<TD><FONT FACE='Verdana,Arial' SIZE=- 
l><B>Phone</B></FONT></TD> 

<TD><FONT FACE='Verdana,Ariar SIZE=-1><B><INPUT TYPE="text" 
NAME="phone" MAXLENGTH=50 SIZE=12></B></FONT></TD> 

</TR><TR> 

<TD><FONT FACE='Verdana,Ariar SIZE=- 
l><B>Email</B></FONTl></TD> 

<TD><FONT FACE='Verdana,Arial' SIZE=-1><B><INPUT TYPE="text" 
NAME="email" MAXLENGTH=50 SIZE=40></B></FONT></TD> 

</TR><TR> 

<TD><FONT FACE='Verdana^riar SI2E=-1><B>CC 
Number</B></FONT></TD> 

<TD><FONT FACE='Verdana,Ariar SIZE=-1><B><INPUT TYPE="text" 
NAME="ccnum" MAXLENGTH=50 SIZE=40></B></FONT></TD> 

</TR><TR> 

<TD><FONT FACE='Verdana,Ariar SIZE=-l><B>Expiration 
(MM/YY)</B></FONT></TD> 

<TD><FONT FACE='Verdana,Ariar SIZE=-l><B>Month <INPUT 
TYPE="text" NAME="ccmexp" MAXLENGTH=50 SIZE=2> / Year <INPUT 
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TYPE="texf • NAME="cqrexp" MAXLENGTH=50 SIZE=2> ... example: 
12/99</B></FONT></TD> 

</TR><TR> 

<TD COLSPAN=2> 

<CENTER> 

<FONT FACE='Verdana,Arial* SIZE=-1><B> 
<INPUT TYPE="submit" VALUE="Reserve Seats"> 
<BR> 

<INPUT TyPE="reset" VALUE="Clear Choices"> 
</B></FOlNrD> 
</CENTER> 
</TD></TR> 
</TABLE> 

</TD></TR></TABLE> 

<iEQ NAME="totar' VALUE=0> 

<iEQ NAME="date" VALUE='<iDATE>'> 

<REM — Begin database command to insert a new customer profile into the 
database. This step is primarily for the purpose of obtaining a new customer id 
to associate this transaction. The customer's ip and captured and inserted into a 
new record in the "customers" table. The marker, "new" is flagged "true" for the 
attrieyal of the new id. Once the new customer id is captured, the marker "new" 
is turned off. — > 

<Markup language DBNAME=:datasource 

database="INSERT INTO customers (ip, new) 
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VALUES (*:LipM)"> 
<database DBNAME=:datasource 

database="SELECT id 

FROM customers 

WHERE new=l"> 

<databaseFETCH> 

<iEQ NAME="custid" VALUE=:1> 
</database> 

<Markup language DBNAME=:datasource 

database="UPDATE customers 

SET new=0 

WHERE id=:custid"> 
<REM — Begin database command to insert a new reservation into the database. 
This step is primarily for the purpose of creating a new reservation record, 
flagged with the newly obtained customer id, so that the transaction information 
may be processed in "resereS.ihtml". — > 

<Markup language DBNAME=:datasource 

database="INSERT INTO orders (orderdate, approvalcode, receiptnum, 
totalcharge, custid) 

VALUES C:date';0000*, ^0000*, :total, :custid)" 
FAILURE=*The order could not be processed at this time due to technical 
difficulties."> 

<REM ~ Begin database command to obtain the reservation id that was just 
created. This information, coupled with the customer id, will be used to identify 
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this particular transaction in the database and be updated in "resere3.ihtml" 
— > 

<database DBNAME=:datasource 

database="SELECT max(id) 

FROM orders"> 

<databaseFETCH> 

<iEQ NAME="oid" VALUE=:1> 
</database> 

<INPUT TYPE="hidden" NAME="reserve" VALUE="receipt"> 
<INPUT TYPE="hidden" NAME=custid VALUE=:custid> 
<INPUT TYPE="hidden" NAME=phone VALUE=:phone> 
<INPUT TYPE="hidden" NAME=email VALUE=:emaU> 
<INPUT TYPE="hidden" NAME=oid VALUE=:oid> 
<Markup language DBNAME=:datasource database='INSERT INTO basket 
(custid, pid, qty) VALUES (rcustid, 6431, l)'><database DBNAME=:datasource 
database='SELECT cost FROM products WHERE 
id=6431'><databaseFETGH><iEQNAME='ticketprice' 
VALlJE=:l></database><iEQ NAME='totar VALUE=<iEVAL 
EXPR=':ticketprice + rtotal' PREC='2'»<Markup language 
DBNAME=:datasource database='INSERT INTO orderdetail (pid, cid, qty, sell) 
VALUES (6431, :oid, 1, :ticketprice)'><Markup language DBNAME=:datasovu:ce 
database='INSERT INTO basket (custid, pid, qty) VALUES (:custid, 6428, 
l)'><database DBNAME=:datasource database='SELECT cost FROM products 
WHERE id=6428'><databaseFETCH><iEQ NAME='ticketprice' 
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VALUE=:l></database><iEQ NAME= 'total' VALUE=<iEVAL 
EXPR=':ticketprice + :totaI' PREC='2'»<Markup language 
DBNAME=:datasource database='INSERT INTO orderdetaU (pid, oid, qty, sell) 
VALUES (6428, :oid, 1, :ticketprice)'><Markup language DBNAME=:datasource 
database=TNSERT INTO basket (custid, pid, qty) VALUES (rcustid, 6429, 
l)'><database DBNAME=:datasource database='SELECT cost FROM products 
WHERE id=6429'><databaseFETCH><iEQ NAME='ticketprice' 
VALUE=:l></database><iEQ NAMEa'total' VALUE=<iEVAL 
EXPR=*:ticketprice + itotal' PREC='2'»<Markup language 
DBNAME=:datasource databases 'INSERT INTO orderdetail (pid, oid, qty, sell) 
VALUES (6429, :oid, 1, :ticketprice)'><Markup language DBNAME=:datasource 
database='INSERT INTO basket (custid, pid, qty) VALUES (:custid, 6430, 
l)'><database DBNAME=:datasource database='SELECT cost FROM products 
WHERE id=6430'><databaseFETCH><iEQ NAME='ticketprice' 
VALUE=:l></database><iEQ NAME='total' VALUE=<iEVAL 
EXPR=':ticketprice + :total' FREC='2'»<Markup language 
DBNAME=:datasource database* 'INSERT INTO orderdetail (pid, oid, qty, sell) 
VALUES (6430, :oid, 1, :ticketprice)'><INPUT TYPE='hidden' NAME='total' 
VALUE=:total></FORM></CENTER><P></BODY></markup language> 
takes in credit card information and passes to: 
<!Markup language> 

<REM — Imports the file "datasource.inc" which creates the variable 
"datasource" which is used to tell Markup language which ODBC datasource to 
connect to. 
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<iINCLUDE NAME="database\datasotirce.inc"> 

<REM - In case a database or other type of error ocoirs, this will display the error 

message. ~ > 

<ERROR> 

<FONT FACE="Verdana,Ariar' SIZE="+l"><B>An Error Has 
Occurred</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>Error Message = 
:i_errortext</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 
:i_databaseerrortext</B></FONT><P> 

<FONT FACE="Verdana,Arial" SIZE="-l"><B>database Error = 

:Ldatabaseerrorstmt</B></FONT><F> 

</ERROR> 

<REM — Begin normal markup language here — > 

<markup language> 

<HEAD> 

<'nTLE>Ticketing & Reservation System - Confirmation< / rH'LE> 
</HEAD> 

<BODY BACKGROUND="images/background.jpg" TEXT="#000000" 
LINK="#006666" VLINK="#006666"> 

<REM — Checks to see if the instance "reserve" with a value of ~ > 
<REM — "receipt" is passed to ttiis page. If so, the codes within — > 
<REM — the iCASE and /iCASE tags are executed. This is primarily — > 
<REM — for security purposes as the instanced "reserved" is only — > 
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<REM — called in the step immediately before. If a visitor — > 
<REM — accidentally stumbled upon this file, nothing will be run — > 
<REM — unless all previous steps are completed. — > 

<iCASE ALIAS="reserve" VALUE="receipt"> 
<CENTER> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=5 CELLSPACING=0 

WIDTH=500> 

<TR><TD> 

<CENTER> 

<FONT FACE='Verdana,Arial* SIZE=+1 COLOR=*#FFFFFF'><B> 

Concert Reservation System 

</B></FONT> 

</CENTER> 

</TI>></TR> 

</TABLE> 

</CENTER><p> 

<REM — Two steps are combined here: — > 

<REM — 1. The reservation ii\formation capttu'ed in — > 

<REM ™ "reserve2.ihtaU" is passed to the iPAY tag which — > 
<REM — processes the information and passes it to CyberCash — > 
<REM — for verification. If successful, the tag returns — > 
<REM — "success", otherwise it returns a variation of "fail" — > 
<REM — 2. ilF checks to see if the verification is a success or — > 
<REM — failure. If successful, it will process the codes — > 
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<REM — immediately after it, which includes updating the — > 
<REM — database with a successful reservation. If anything — > 
<REM — other than "success" is returned, iEF will skip to — > 
<REM — the iELSE tag and execute all codes thereafter. — > 
<iIF COND=<iPAY SERVER="C3" 

amount=: total 

id=:oid 

ccnum=":ccnum" 

ccmexp=":ccmexp" 

ccyexp=":ccyexp" 

name=":name" 

capture="false" 

HOST="http:/ /cr.cybercash.com/cgi-bin" 
PORT=80 
SECRET='Vendorid-26" 

CRYPTOKEY="jlylolohNUlciTdPFlhsvHFjIpnCpR"» 

<CENTER> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=0 CELLSPACING=0> 
<TR><TD> 

<TABLE BGCOLOR='#FFFFFF^ BORDER=0 CELLPADDING=5 CELLSPACING=1 

WIDTH=500> 

<TR><TD> 

<FONT FACE="Verdana,Arial" SIZE="-1"> 
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<B>The credit card has been approved and the reservation has been 
processed.<P> 

The following are the Authorization Code and Receipt Number:</B><p> 
<b>Authorization Code:</b> :i^pay_authnumber<BR> 
<b>Receipt Number:</b> :i_pay_transactiormumber<P> 
<b>Customer Naine:</b> :name<BR> 
<b>Total Amount</b> $:total<BR> 
<b>Credit Card Number:</b> :ccniim<BR> 
<b>Month of Expiration:</b> :ccmexp<BR> 
<b>Year of Expiration:</b> :ccyexp<BR> 

<REM ~ Begin database query to update the "customers" table with customer 
information captured in "reserve2.ihtml". — > 

<Markup language DBNAME=:datasource 
database="UPDATE customers 

SET con tact= '.name*, phone=':phone*, email=*:emair 

WHERE id=:custid"> 
<REM ™ Begin database query to update the "orders" table is updated with the 
approval code returned by CyberCash, as well as the transaction iriformation 
(total charge, credit card number, etc). — > 

<Markup language DBNAME=:datasource 

database="UPDATE orders 

SET approvalcode=*:i_pay_authnumber*, 
receiptnum=':i_pay_transactionnumber', totalcharge=:total,cc=*:ccnum*, 
ccm=':ccmexp*, ccy=*:ccyexp* 
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WHERE id-:oid" 
FAILURE="The infonnation was not saved correctly. <br>"> 
<REM — Begin database query to turn off the availability of the seats that have 
been reserved by setting the "active" attribute of the seats to "0". 
-.-> 

<database ALIAS="markoff ' dbname=":datasource" database="SELECT pid 
FROM orderdetail WHERE oid=:oid"> 

<databaseFETCH ALIAS="markoff'> 
<iWHILE NOTALIAS=i_databaseempty> 

<Markup language dbname=":datasource" 
database="UPDATE products 
SET active=0 

WHERE id=:markoff_pid"> 
<databaseFETCH ALIAS="markofr> 
</iWHILE ALIAS=i_databaseempt)r> 
</database ALIAS="markofr> 
</FONT> 
</TD></TR> 
</TABLE> 
</TD></TR> 
</TABLE> 
</CENTER><p> 
<iELSE> 
<CENTER> 
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<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=0 CELLSPACING=0> 
<TR><TD> 

<TABLE BGCOLOR='#FFFFFF' BORDER=0 CELLPADDING=5 CELLSPACING=1 

WIDTH=500> 

<TR><TD> 

<FONT FACE="Verdana,Arial" SIZE=".1"><B> 

This transaction could not be processed by Cyber Cash at this time. Either the 

Credit Card Information was invalid or the Cyber Cash server is currently not 

available. 

</B></FONT> 

</TD></TR> 

</TABLE> 

</TD></TR> 

</TABLE> 

</CENTER> 

</iIF> 

<FORM ACTION="index.ihtmr' METHOD="post"> 
<CENTER> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=0 CELLSPACING=0> 
<TR><TD> 

<TABLE BGCOLOR='#FFFFFF' BORDER=0 CELLPADDING=5 CELLSPACING=1 

WIDTH=500> 

<TR><TD> 

<CENTER> 
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<FONT FACE="Verdana^rial" SIZE="-1"><B> 

<INPUT TYPE="submit" VALUE="Retum to Concert Selection"> 

</B></FONT> 

</CENTER> 

</TD></TR> 

</TABLE> 

</TD></TR> 

</TABLE> 

</CENTER> 

</FORM> 

<FORM ACTION="http://domainname/menaine" METHOD="post"> 
<CENTER> 

<TABLE BGCOLOR='#000000' BORDER=0 CELLPADDING=0 CELLSFACING=0> 
<TR><TD> 

<TABLE BGCOLOR='#FFFFFF' BORDER=0 CELLPADDING=5 CELLSPACING=1 

WIDTH=500> 

<TR><TD> 

<CENTER> 

<FONT FACE="Verdana,Ariar' SIZE="-1"><B> 

<INPUT TYPE="submit" VALUE="Retum to On-Line Ticketing & Reservation 
Front Desk"> 

</B></FONT></CENTER> 

</TD></TR></TABLE></TD></TR></TABLE></CENTER> 
</FORM> 
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</iCASE ALIAS="reserve"> 
</BODY> 

</markup languago 

which verifies and confirms payment information 

End Figtire 5 
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<!— Begin Code 1 1 ~> 

<! — Defines the underlying image to lay the image niap code over / / — > 

<i]MAGEFROMFILE NAME="section" FILENAME ="images/map/ sections/: b: 
imagetype" TYPE="jpeg"> 

<! — Defines the image sotirce as a variable // — > 

<MAP NAME="section"> 

<! — Opens ODBC connection // > 

<iSQL DBNAME=":datasOurce" 

SQL="SELECT id, seatSection, seatRow, seatNumber, seatPrice, 
seatAvailability, seatTemporary, y, shape, coords 

FROM seats 

WHERE seatSection=':b"' 
ALIAS="seats"> 

<!— Performs SQL loop // — > 

<iSQLFETCH ALL^S="seats"> 

<iWHILE NOTALL\S=i_sqlempty> 

<! — Defines and popiilates seat availability and tempoary status // — > 

<iEQ NAME="available" VALUE=:seats_seatAvailability> 
<iEQ NAME="temporary" VALUE=: seats_seatTemporary> 

<! — Begin conditions for temporary "?", reserved "X" or open seating 
//--> 

<!— Defines the condition if a seat is available // — > 

<iCASE AUAS="available" VALUE=1> 
<! — Defines the condition if a seat is currently being reserved // — > 

<iCASE ALIAS="temporary" VALUE=1> 



<! — Instructs iHTML to put a "?" over the coordinates retrieved from the 
DB // -- > 

<iIMAGETEXT NAME="section" text="?" x=:seats_x 
y=:seats_y color="red"> 

</iCASE AIJAS="temporary"> 



wo 00/65506 



40 / 41 



PCT/USOO/10686 



<! — Defines the condition if a seat is not currently being reserved // — > 

<iCASE ALIAS="temporary" VALUE=0> 
<iEQ NAME="seatPrice" VALUE=<iEVAL 
EXPR=" :seats_seatPrice" PREC=2» 

<!— Instructs iHTML to write the image map coordinates retrieved from the DB to 
make the area clickable // — > 

<AREA SHAPE=":seats _ shape" CCX)RDS=": seats_coords" 
HREF="angelsReserveList.ihtml?a=:a&seatlD=:seats_id&seatSection=:seats_seatSection 
&seatRow=:seats_seatRow&seatNumber=:seats_seatNumber&seatPrice=: 
seats_seatPrice&option =add" TARGET='Xist" ALT="Section #seats_seatSection, 
Seat#:seats_seatRow-:seats_seatNumber" OnMouseOut="window. status="; return . 
true" OnMouseOver="window.status= "Reserve Seat 
:_seats_seatRow-:seats_ seatNtimber of Section:seats_seatSection— $ 
:seatPrice'; return true"> 

</iCASE ALIAS="temporary"> 

</iCASE ALIAS="available''> 

<! — Defines the condition if a seat is NOT aviailable // — > 

<iCASE ALIAS="available" VALUE=0> 

<! — Instructs LHTML to put a 'X' over the coordinates retrieved from the 
DB//~> 

<IIMAGETEXT NAME="section" text="X" x=:_seats_x 
y=:seats_y color="red"> 

</iCASE ALIAS="avaiIable"> 

<1— Ends SQL loop / / ™ > 

<iSQLFETCH ALIAS="seats"> 
</iWHILE AIIAS= i_sqlempty> 

<!-- Closes ODBC connection //— > 

</iSQL ALIAS="seats"> 

</MAP> 

<! — Writes the final image into a physical file // — > 
<iIMAGEWRITE NAME="section" 

FILENAME="images/map/sections/section-:b-:imagenum:imagetype"TYPE="jpeg" 
QUALITY="25"> 
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<! — Removes the image source from memory // — > 
<iIMAGEDESTROY NAME="section"> 
<!— End Code //— > 
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